The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Remote Procedure Call (RPC) is a mechanism that allows one computer program procedure (the calling procedure) to call another procedure (the called procedure) where the calling procedure and the called procedure are established in different execution contexts that usually reside on physically separate computer systems that are linked by communication links or networks. By defining the execution semantics and protocols for making remote procedure calls, the RPC mechanism provides a procedure execution paradigm in which a calling procedure can make a RPC call to a called procedure executed on a remote computer system, where the RPC call may provide input parameters for the called procedure and may receive results returned from the called procedure. One specification of a RPC mechanism is the DCE 1.1 RPC specification, which can be found at http://www.opengroup.org/onlinepubs/9629399/toc.htm.
RPC mechanisms generally follow a client-server execution model. For example, a client established on a network usually requests the execution of a remote procedure from a remote service that is provided by a server established in the same or different network. To request the execution of the remote procedure, the client executes a calling procedure that makes a RPC call to the remote procedure on the remote service. The remote service on the server executes the remote procedure and provides the results back to the client.
As referred to herein, a RPC request is a request to a remote service to execute one or more operations. The one or more operations may be implemented as one or more remote procedures. A remote service that is capable of executing operations on behalf of a client is referred to herein as a RPC service, and the operations that can be executed by the RPC service are referred to herein as RPC operations. An RPC operation is one or more sequences of instructions that are entered from, and return control to, an external source. For example, an RPC operation may be executed by a RPC service in response to an RPC call that is invoked from a calling procedure on a client and that is included in a RPC request. After executing the RPC operation, the RPC service returns the results to the calling procedure in a RPC response.
In addition to providing the execution semantics for calling a procedure remotely, RPC mechanisms also provide for a sequence of communication protocols that define a communication channel between a client and a remote service. In order to exchange RPC requests and RPC responses, the client and the remote service agree on a common sequence of protocols and on the operational parameters of these protocols. A typical implementation of a RPC mechanism includes a network protocol, a transport protocol, and a RPC protocol. The communication protocols are usually layered, and the client and the remote service provide the addressing information that indicates to a protocol at a particular layer where to deliver the data for the protocol at the adjacent layer.
For example, in one implementation of a RPC mechanism, the client and the remote service may communicate over Transmission Control Protocol (TCP) connection. The client and the remote service exchange TCP packets over a TCP socket, which comprises an Internet Protocol (IP) address and a TCP port number for the client and an IP address and TCP port number for the remote service. The RPC requests and RPC responses exchanged by the client and the remote service are included in the payload portion of the TCP packets. In another implementation of a RPC mechanism, the client and the remote service communicate over a pipe Interprocessor Communication Mechanism (IPC), which is established over a Server Message Block (SMB) protocol. The SMB protocol identifies the pipe by a logical filename or a file handle of a file that is usually stored on the server that provides the remote service. The client and the remote service exchange RPC requests and RPC responses by reading from and writing to the file that is identified by the logical filename or the file handle.
The RPC relationship established between a client and a remote service is expressed as a binding. The binding includes information that associates a client's RPC call with the remote service's implementation of the RPC operation requested by the RPC call. In some implementations of RPC mechanisms, the binding information includes a sequence of communication protocols and network address information of the client and the remote service. The sequence of communication protocols is a valid combination of protocols, such as, for example, the combination of a network protocol (such as, for example, IP), a transport protocol (such as, for example, TCP), and a RPC protocol (such as, for example, Microsoft RPC (MS-RPC)). The network address of the client and the remote service provides complete transport address information of the client and the remote service. In a typical implementation of the RPC mechanism, a client must first execute one or more RPC calls in order to establish a transport connection to the remote RPC service. The client then needs to execute one or more RPC calls to establish a binding to the remote RPC service before the client can execute a RPC call for a remote operation provided by the remote RPC service.
Typically, a RPC mechanism is implemented by the Operating Systems (OS) executing on a client and a remote service. Since the client and the remote service are usually executing on physically separate computer systems, the RPC mechanism is inevitably utilized over a network or over some other type of communication link. When the network or the communication link over which a RPC call is made is relatively slow, use of the RPC mechanism may cause significant execution latency in a client that is relying on the RPC mechanism to utilize a particular remote RPC service, and the users of the client may experience delays in receiving services.
This problem is particularly acute when the RPC mechanism and the RPC calls it provides for are utilized by computer systems deployed in geographically dispersed enterprise networks. A geographically dispersed enterprise network may include a number of Local Area Networks (LANs) that are connected over one or more Wide Area Network (WAN) communication links. The geographically dispersed enterprise network usually includes one or more servers that provide one or more RPC services. The RPC services may be configured to respond to RPC requests received from other enterprise servers or clients, which servers or clients may be established in a remote LAN that is located across the WAN. The use of RPC mechanisms in such geographically dispersed enterprise networks may cause significant latency problems because a client established in a local LAN may have to make a series of RPC calls over a slow WAN link to a remote service established in a remote LAN.
For example, suppose that a user of a client in a local LAN wants to browse through a list of shares that are exported by a server in a remote LAN. In response to a request from the user for a listing of the exported shares, the client first executes an RPC call to open a pipe to a remote RPC service in the remote LAN. The RPC call is transmitted over the WAN to the remote RPC service, and the remote RPC service sends back an RPC response indicating that the pipe is open. The client then executes a second RPC call to bind the client to the remote RPC service, and waits for the remote RPC service to send back a RPC response. When the client receives the RPC response indicating that the binding succeeded, the client sends one or more RPC calls requesting a listing of the shares. In response to the one or more RPC calls, the remote RPC file service sends back one or more RPC responses with the listing of the shares. In order to complete the user request, the client then sends an RPC request to close the pipe, and the remote RPC file service responds with a RPC response indicating that the pipe is closed. Thus, in order to get the listing of the shares exported by the remote server, at least four roundtrip RPC communications were exchanged between the client and the remote RPC file service over the slow WAN link. If thereafter the user decides to request information about a particular share, another at least four roundtrip RPC communications need to be exchanged over the WAN link.
Thus, significant latency and performance degradation are observed at the client when a RPC operation needs to be performed at a remote RPC service that is located across the WAN in a remote LAN. Since the client must perform each RPC call on the remote service by sending sequences of RPC communications over a slow WAN link, the latency in response times from the user's perspective tends to be high. Even if the WAN link has sufficient bandwidth, the WAN latency still causes the execution of the RPC call to be slow. This problem is exacerbated when the user activity involving RPC calls to a RPC service across the WAN is repeated or comes in bursts of several repeating RPC call sequences.
Based on the foregoing, there is a clear need for a technique that provides for optimization of RPC communications exchanged over a slow communication link.